The following abbreviations are utilized herein:    802.11s mesh networking described by the IEEE 802.11s draft amendment    ACK acknowledgment (acknowledgment message)    AP access point    ATIM announcement traffic indication message    BC broadcast    BSS basic service set    DTIM delivery traffic indication message    FBMS Flexible Broadcast and Multicast Service    GAS generic advertisement service    IBSS independent basic service set    IEEE institute of electrical and electronics engineers    MAC medium access control (layer 2, L2)    MAP mesh access point    MC multicast    MIB management information base    MIMO multiple input/multiple output    MP mesh point    MSDU MAC service data unit    PGT post groupcast time    PS power save    STA station    TBTT target beacon transmission time    TIM traffic indication message    WiMAX worldwide interoperability for microwave access (IEEE 802.16 standard)    WLAN wireless local area network
One publication of interest to the ensuing description is:
IEEE P802.11s™/D1.08, Draft STANDARD for Information Technology-Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Mesh Networking (January 2008).
In accordance with draft 1.08 of 802.11s, coordination of devices within radio range is achieved by the exchange of beacon frames. Periodic beacon transmission enables device discovery, supports dynamic network organization, and provides support for mobility.
As described in the IEEE P802.11s™ Draft Standard, in section 5.2.9.1 “Introduction to mesh”, in WLAN deployments without mesh services, stations (STAs) must associate with an access point (AP) in order to gain access to the network. These STAs are dependent on the AP with which they are associated to communicate. An example of a nonmesh WLAN deployment model and device classes are illustrated herein in FIG. 1, which reproduces FIG. s1 of the IEEE P802.11s™ Draft Standard.
Many WLAN devices can benefit from support for more flexible wireless connectivity. Functionally, the distribution system of an access point can be replaced with wireless links or multihop paths between multiple APs. Devices traditionally categorized as clients can benefit from the ability to establish peer-to-peer wireless links with neighboring clients and APs in a mesh network.
An example mesh is illustrated in FIG. 2, which reproduces FIG. s2 of the IEEE P802.11s™ Draft Standard. Mesh points (MPs) are entities that support mesh services, i.e., they participate in the formation and operation of the mesh network. An MP may be collocated with one or more other entities (e.g., AP, portal, etc.). The configuration of an MP that is collocated with an Access Point is referred to as a MAP. Such a configuration allows a single entity to logically provide both mesh functionalities and AP functionalities simultaneously. STAs associate with APs to gain access to the network. Only MPs participate in mesh functionalities such as path selection and forwarding, etc. Mesh portals (MPPs) interface the network to other IEEE 802 LAN segments.
As is stated in section 5.2.9.2, “Mesh network model”, of the IEEE P802.11s™ Draft Standard, a mesh network is an IEEE 802 LAN comprised of IEEE 802.11 links and control elements to forward frames among the network members. Effectively, this means that a mesh network appears functionally equivalent to a broadcast Ethernet from the perspective of other networks and higher layer protocols. Thus, it normally appears as if all MPs in a mesh are directly connected to the link layer. This functionality is transparent to higher layer protocols. Reference in this regard can be made to FIG. 3A, which reproduces FIG. s-3 of the IEEE P802.11s™ Draft Standard. It should be noted that while this figure shows the forwarding of data over multiple hops, there may also be direct data transfer over a single hop, such as is shown in FIG. 3B, wherein the source and destination of the MSDUs are within a one-hop neighborhood, and where no forwarding, routing or link metric need be used.
In an infrastructure Basic Service Set (BSS), stations rely on the AP for power saving. A station informs the AP before switching from active mode to power save mode. If any STA in BSS operates in power save mode, the AP buffers multicast or broadcast traffic and delivers them after the Delivery Traffic Indication Message (DTIM) beacon. The DTIM interval is a multiple of beacon periods. For unicast traffic that is buffered in the AP, stations periodically need to wake up to receive the Traffic Indication Map (TIM) that is present in all beacon frames. Having learned from a beacon frame that unicast traffic directed to the station is pending, a station sends out a Power Save (PS)-Poll frame or APSD trigger frame to request the traffic's delivery from the AP.
In an independent Basic Service Set (IBSS) mode, also known as ad-hoc, the basic approach is similar to the infrastructure BSS case in that the STAs are synchronized, and multicast traffic and the traffic that are to be transmitted to a power-conserving STA are first announced during a period when all STAs are awake. The announcement is accomplished via a message sent in an Announcement Traffic Indication Message (ATIM) Window. A STA in the power save mode shall listen for these announcements to determine if it needs to remain in the awake state. The presence of the ATIM window in the IBSS indicates if the STA may use the PS Mode. To maintain correct information on the power save state of other STAs in an IBSS, a STA needs to remain awake during the ATIM window. At other times the STA may enter the doze state.
The current IEEE 802.11s specification defines an efficient power saving mechanism, which reduces the amount of time during which the MP should remain awake. However, neighboring MPs should be able to know when a peer MP is awake and accessible for transmission of unscheduled frames. This is achieved by the use of an Awake Window, which is present after delivery traffic indication message (DTIM) beacons, and may be included after traffic indication map (TIM) beacons and the probe response frame. The Awake Window is defined in such way that a power saving MP is to remain awake for the duration of the Awake Window after a Beacon with an Awake Window element. The DTIM period is defined per mesh point.
However, this approach can be disadvantageous when the Awake Window is also used to transmit broadcast and multicast frames, as the duration of the Awake Window should include time for multicast and broadcast frame transmission, as well as time for peer service period triggering. If a network has a high traffic load it may be the case that the multicast and broadcast frame transmissions do not all fit within the Awake Window and are thus transmitted after the Awake Window. This reduces the network efficiency when the MP must wait until the next Awake Window to have an opportunity to transmit frames other than multicast and broadcast frames.
Another problem with multicast and broadcast frames is that they are not acknowledged by the receiver. As a result a transmitting MP cannot know if the peer MP(s) have received a last multicast or broadcast frame, which includes an indication that there will not be any additional frames to be received. Absent this information the peer MP must stay awake until the next beacon transmission, thereby needlessly consuming power.